Traditional personal computers (PCs) are being replaced with simpler devices in “mission-critical” environments such as healthcare. So-called terminal devices provide only basic presentation (display), networking, and device-redirection services (to support, for example, keyboard, mouse, audio, and USB devices) for server-based computing—i.e., architectures in which a sophisticated remote server supplies applications or even entire desktops to the terminal device. The user interacts with the server-provided functionality via “receiver” or “terminal-emulation” software (or firmware) running on the terminal device, ideally rendering the experience indistinguishable from using local applications running on a conventional PC. The trend favoring these “thin” or “zero” client devices is driven by the desire to eliminate data at the edge of a computer network where it is vulnerable to compromise; to centralize the management of computing resources on highly available hardware; and to simplify management and support of the endpoint devices.
Thin clients may utilize system-on-chip (SOC) designs, which allow hardware device vendors to incorporate all the necessary computing, display, networking, audio, video, and USB device capabilities into one low-cost integrated circuit capable of running directly from “firmware”—i.e., basic system-level programming—stored on non-volatile (e.g., flash) memory. Firmware delivered by the hardware vendor typically comprises the base operating system (such as LINUX, UNIX, RTOS, etc.) combined with specialized programming that facilitates interfacing with device components for display management, 2D/3D graphics, imaging, and audio-visual coder/decoders (codecs), and supports external devices attached by the user (e.g., via USB ports). Terminal-emulation programs furnished with the thin client support a rich user experience through remote interaction with applications actually executing on the back-end servers; these programs use networks protocols such as RDP (Remote Desktop Protocol), ICA (Independent Computing Architecture) or PCoIP (PC over IP).
Ideally, firmware delivered on a thin client device remains up-to-date for the life of the hardware with no need to “re-flash” (i.e., remotely replace the firmware via a computer network). This frees local information-technology (IT) support personnel from managing installed firmware. In reality, however, firmware is periodically updated to fix bugs or to support new features or devices. Moreover, for certain types of firmware applications, the ability to modify the firmware is desirable for the purposes of ensuring proper functioning and/or customizing the applications. This is especially relevant for user-authentication-service (UAS) firmware that runs on the SOC to validate a user's identity prior to launching the terminal-emulation program with the correct user credentials. Because the UAS firmware generates the user interface (UI), both intermediate resellers and end-user customers often seek to customize the UAS in order to promote their own corporate branding, e.g., to display a hospital's mission or corporate logo when the device is in its ready state waiting for a user to log on. This requires the firmware to be field-modified for each customer—an impossibility for device-provided firmware. In addition, since the UAS is the authentication point for the entire system (all the way to the server hosting the desktop and end-user applications), the integrity of the firmware should be verifiable at any time to ensure that it has not been compromised.
The hardware vendor that supplies the client device typically facilitates updating the firmware via a management console that broadcasts new firmware versions to customers (in accordance with the maintenance policy in effect) and manages their installation remotely. This procedure performs a complete update of the firmware while optionally preserving settings or personalization already applied. But it leaves the hardware vendor in charge of when these updates occur. Moreover, a full upgrade to the system firmware can impose a considerable amount of down time since the device is inoperable during the upgrade—and particularly in fast-paced environments such as healthcare facilities, such delays may not be tolerable.